| Message Constraints for the ED datatype when used with PresentationText | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Programme | NPFiT | DOCUMENT NUMBER | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sub-Prog/Project | Comms and Messaging | National Prog | Org | Prop/Proj | Doc Type | Seq | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Prog. Director | Paul Jones | NPFIT | FNT | TO | DPM | 0443.01 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sub-Prog/Proj Mgr | Kenneth Lunn | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Author | C&M Development Team | Version No | 1.5 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| NPQ/PSO Contact | Richard Kavanagh | Status | Issued | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Change history
| Version | Date | Amendment History |
| 1.0 | 28/10/2005 | First version |
| 1.1 | 28/02/2006 | Changes for the new datatype flavour of ED.NPfIT.Text.XHTML. Changes to the schemas are documented here. |
| 1.2 | 03/04/2006 | Changed fragment demonstrating use of external links in section 4.8 |
| 1.3 | 16/08/2006 | Changed Presentation Text XHTML xmlns attribute to "xhtml:NPfIT:PresentationText" |
| 1.4 | 31/10/2006 | Removed reference to plain text |
Contents
This document specifies how to use the ED data type to convey textual information within the Core CRS messages ( such as GP summary ).
In Core CRS, it is not permitted to include any binary data within these ED data types. Therefore, the use of images, word documents or PDFs, for example, is excluded. Data must either be plain text or a specific form of XHTML mark up described below. Structured text blocks sent in messages need to validate against the xhtmlNPfITPresentationText schema.
Many media types can be catered for within an ED data types but only two are allowed in the Core CRS messages:
There is a Flavour of ED called ED.NPfIT.Text.XHTML which only allows the following:
A restricted version of HTML. Designed for use with formatted marked up documents. This flavour carries a mediaType Attribute which is mandatory and has a fixed value of "text/plain". The default character set for XHTML is UTF-8.
These restrictions are specifically designed to prevent :-
<value
mediaType="text/plain"
>
<html
xmlns="xhtml:NPfIT:PresentationText">
<head>
</head>
<body>
<p>The lung
fields are clear. Heart size is enlarged with slight unfolding of the aorta.</p>
<p>CTR =
18/35 cm</p>
<p>The right
hemi-diaphragm is raised</p>
</body>
</html>
There is a mapping provided in the table below which indicates how this constrained XHTML maps to the HL7 CDA body structures. The structures defined here are more constrained than CDA, but will map to a true subset of that document definition.
If formatted text is a requirement then a subset of XHTML (with CfH specific XML extensions) rather than HTML shall always be used.
The main implications of this are:
<table summary="1"> But ...<table summary=1> generates a parser error.
Note <h1> and <title> are not permitted as they are reserved for use by the host application ( e.g. CSA ).
|
Tag |
Description |
Usage |
Permitted attributes |
Mapping to HL7 CDA |
|
<html> |
Top level element containing an instance of <head> and an instance of <body>. |
Structural |
xmlns |
|
|
<head> |
One instance only in the <html> element. |
Structural |
|
|
|
<body> |
One instance only in the <html> element following the <head> and containing the remainder of the document. |
Structural |
|
|
|
<h2> |
Heading levels. Restriction: These are not permitted to contain any sub-elements. |
Used to represent headings and their relative position within the document contents |
id, class |
section |
|
<p> |
Paragraph |
Used to contain data as paragraphs |
id, class |
paragraph |
|
<ol> |
Outline list numbered and unnumbered. |
Used to contain data as numbered or unnumbered lists. Unnumbered lists may be rendered in any order. Numbered lists must be rendered in number order. Lists may contain other lists as sublists. |
id, class |
list |
|
<li> |
List item |
A list item in a list |
id, class |
item |
|
<table> |
Table |
Used to contain data in a tabular form. May not be used to control layout, grouping or positioning of data |
summary, id, class |
table |
|
<caption> |
Table caption |
Must appear immediately after the <table> start tag. |
class |
|
|
<thead> |
Table header |
Used to define a table header |
id, class |
thead |
|
<tfoot> |
Table footer |
Used to define a table footer |
|
tfoot |
|
<tbody> |
Table body |
Used to define a table body |
id, class |
|
|
<tr> |
Table row |
Used to define a row in a table |
id, class |
tr |
|
<td> |
Table cell |
Used to define a cell in a table. |
id, rowspan, colspan, abbr, headers |
td |
|
<th> |
Table header cell |
Used to define a header cell in a table. |
id, class |
|
|
<a> |
Internal links Restriction: The href URL for an internal link must start with #, indicating that it is a pointer into the current document. |
Used to mark data as being linked to an internal reference. Note this link is for document navigation purposes and must create no clinical or semantic meaning |
id, href="#...." iiref, class |
link_html |
|
<br/> |
Section break |
The use of <br/> will be defined via separate rendering guidance. Its use is not discussed here. |
|
|
|
<pre> |
Preformatted text This has been included to represent fixed width fonts where the layout is controlled by whitespace, as for the pathology result messages. |
|
id, class |
|
Note: Style has been removed from the previous documentation as it was identified as a candidate for deletion. Quotation markup will also not be used for inline quotes as language independence is not a requirement.
The html element does not have a version attribute. A npfit: version foreign attribute to identify any versions of the NPFIT subset of the XHTML specification (other than the initial one) would require adding if necessary.
Style is not a permitted attribute.
It is the sender’s responsibility to ensure information is represented safely and appropriately with this attribute absent.
A number of classes will be predefined to assist styling and context of information within the structured text message.
Internal and external links may be present in the XML document. The use of external links is currently limited to pds/sds links only. Other types of links (e.g. links to external images, statements etc) are not permitted.
Note that for clarity namespace attributes are omitted from <html> start tag within examples.
Internal references are made using the id and href attributes of the <a> tag. The id attribute defines the target of an internal link and the href attribute provides a reference to the internal target. Note that the href attribute is limited to the href=”#..” semantic (which limits it to internal links only).
Note that the id attribute must be unique within the xml fragment sent. If fragments are combined then ids may have to be changed, unless a globally unique scheme can be defined for use.
e.g.:
<html>
<body>
<h2>Contents</h2>
<ul>
<li><a href=”#section1”>Section 1</a></li>
<li><a href=”#section2”>Section 2</a></li>
</ul>
<h3><a id=”section1”>Section 1</a></h3>
<p>Section 1 text</p>
<h3><a id=”section2”>Section 2</a></h3>
<p>Section 2 text</p>
</body>
</html>
External references are made using the iiref attribute of the <a> tag. The iiref attribute defines the target of an external link. This is a NPfIT defined attribute which will be prefixed by a NPfIT specific namespace reference. The use of external links is currently limited to pds and sds links only.
Note that links into sds and pds may be defined for use as values within the @class attribute for rendering purposes. This will be defined via separate rendering guidance.
A fragment demonstrating iiref use is as below:
Report produced by <a npfit:iiref="2.16.840.1.113883.2.1.4.1" id="1234567890">Dr John Smith</a>
Note that the structured text must contain the de-normalised iiref content including at least the name of the referenced person, organisation, etc.
Preformatted text has been included to represent fixed width fonts where the layout is controlled by white space, as for the pathology result messages.
The sending system is responsible for converting any tabs to spaces when sending a message to avoid misaligned text.
<pre> must only be used as a direct child element of <body>. Its use elsewhere (such as within table structures) in explicitly forbidden.
Tables are complex structures that can be difficult to render in an accessible way. Therefore, a specific table structure is required from sending systems to ensure that a table can be accessibly rendered by a receiving system.
The general structure of a table to be used is:
<table summary=”A summary of the contents of a table”>
<caption>Table Caption</caption>
<!-- Table Header -->
<thead>
<tr>
<th>Table Header 1</th>
<th>Table Header 2</th>
….
</tr>
</thead>
<!-- Table Footer-->
<tfoot>
<tr>
<td>Table Footer 1</td>
<td>Table Footer 2</td>
….
</tr>
</tfoot>
<!-- Table Body -->
<tbody>
<tr>
<td>Table Content Row 1 Column 1</td>
<td>Table Content Row 1 Column 2</td>
…
</tr>
<tr>
<td>Table Content Row 2 Column 1</td>
<td>Table Content Row 2 Column 2</td>
…
</tr>
…
</tbody>
</table>
The table Structure is defined using the <table> tag. Within the table tag, the following attributes are allowed:
The table caption will describe the title and/or nature of what is contained within the table. The <caption> element is only permitted immediately after the <table> start tag.
The table header consists of one or more table rows (each containing table cells). These rows are contained within a <thead> tag. These rows are used to define the contents of columns within the table. The table row(s) and cells can take any attribution allowed for these tags.
Support is for two dimensional tables only. Table should not be used for indentation or alignment of semantically unrelated items.
The transformation rules for <thead> are to be in separate rendering guidance.
The table footer consists of one or more table rows (each containing table cells). These rows are contained within a <tfoot> tag. These rows are typically used to contain sums of column data etc. The table row(s) and cells can take any attribution allowed for these tags.
The table footer must appear before the <tbody> element so that user agents can render the foot before receiving all of the (potentially numerous) rows of data.
Table rows and cells are used to contain the data content of the table. Each row will contain a number of cells. The number of cells in a row should not exceed the number of cells in the header to avoid orphan cells appearing in the table with no header.
A table row is defined by the <tr> tag and may contain many cells. A cell is defined by a <td> tag and may contain data or the following tags only:
The td tag allows the following attributes:
These attribute are optional for senders.
For tables with more than one header row or with <th> defined within <tbody>, the @headers values should be defined by the sending system.
Note that any header specified must visually line up.
Abbr may be optional for implementation by receiving systems (although its use assists in providing an accessible interface). Therefore, senders must ensure that the document is clinically safe if this attribute is not used.
The use of ‘abbr’ attribute is as per XHTML and WAI guidelines. Note that the ‘abbr’ attribute should not be defined for table cells that are to appear in the table body.
Certain ASCII characters should not be used within XML/XHTML or even plain text fragments as they have a special meaning. Whereas this applies to all data types problems are most likely to arise within Encapsulated Data or Strings. Therefore the following characters must only be used via the appropriate entity name.
| Character | Description | Entity Name |
| " | quotation mark | %quot; |
| ' | apostrophe | ' |
| & | ampersand | & |
| < | less-than | < |
| > | greater-than | > |
e.g. The following will cause syntactical errors in a message due to the presence of a ampersand character:
<value>Patient was sent to A & E</value>
It should be expressed as:
<value>Patient was sent to A & E</value>
More information can be found at http://www.w3.org/TR/xhtml1